<HTML>
<HEAD>
  <STYLE type="text/css">
    H1 {color: black }
    H2 {color: maroon }
    H3 {color: #007090 }
    A.head:link {color: #0060a0 }
    A.head:visited {color: #3040c0 }
    A.head:active {color: white }
    A.head:hover {color: yellow }
    A.red:link {color: red }
    A.red:visited {color: maroon }
    A.red:active {color: yellow }
  </STYLE>
</HEAD>
<TITLE>Magic-8.3 Command Reference</TITLE>
<BODY BACKGROUND=graphics/blpaper.gif>
<H1> <IMG SRC=graphics/magic_title8_3.png ALT="Magic VLSI Layout Tool Version 8.3">
     <IMG SRC=graphics/magic_OGL_sm.gif ALIGN="top" ALT="*"> </H1>

<H2>lef</H2>
<HR>
LEF-format input and output
<HR>

<H3>Usage:</H3>
   <BLOCKQUOTE>
      <B>lef</B> <I>option</I> <BR><BR>
      <BLOCKQUOTE>
         where <I>option</I> may be one of the following:
	 <DL>
	   <DT> <B>read</B> [<I>filename</I>]
	   <DD> Read a LEF file named <I>filename</I>[<B>.lef</B>]
	   <DT> <B>read</B> [<I>filename</I>] <B>-import</B>
	   <DD> Read a LEF file.  Import standard cells from <TT>.mag</TT>
		files
	   <DT> <B>read</B> [<I>filename</I>] <B>-annotate</B>
	   <DD> Read a LEF file.  Use any macros defined in the LEF file
		to annotate existing layouts, and ignore all other macros.
	   <DT> <B>write</B> [<I>cell</I>] [<B>-tech</B>]
		[<B>-hide</B> [<I>distance</I>]] [<B>-toplayer</B>]
		[<B>-pinonly</B> [<I>distance</I>]] [<B>-nomaster</B>]
	   <DD> Write LEF for the current or indicated cell.<BR>
		Option <B>-tech</B> writes the technology information (layer
		mapping and rules) to the same file as the cell macro. <BR>
		Option <B>-hide</B> generates an abstract view that has all
		interior detail removed, leaving only pins and obstruction
		layers covering the entire cell with cut-out areas for the
		pins.  Option <B>-hide</B> may take an additional value
		argument <I>distance</I> which will hide the central part
		of a cell starting a distance <I>distance</I> from the edge.
		The <I>distance</I> value is in units of lambda by default,
		but like other distance measurements changes with respect
		to the <B>snap</B> command setting, and can take a suffix
		such as "<B>um</B>" to specify a physical distance relative
		to the current CIF/GDS output scale. <BR>
		Option <B>-toplayer</B> outputs pin geometry only for the
		topmost layer belonging to the pin;  all connected layers
		underneath will be output as obstructions. <BR>
		Option <B>-pinonly</B> will mark only areas that are port
		labels as pins, while marking the rest of each related net
		as an obstruction.  Value <I>distance</I>, if given, will
		extend any pin beyond the marked port label along the length
		of the same net, to the specified distance into the interior
		of the cell. <BR>
		Option <B>-nomaster</B> will prevent the generation of
		output geometry on layers defined as MASTERSLICE.
	   <DT> <B>writeall</B> [<B>-tech</B>] [<B>-hide</B> [<I>distance</I>]]
		[<B>-notop</B>] [<B>-toplayer</B>] [<B>-nomaster</B>]
	   <DD> Write all cells including the top-level cell.  This might
		be appropriate if the top-level cell is a compendium of
		standard cells. <BR>
		With option <B>-notop</B>:  Write all subcells of the top-level cell,
		but not the top-level cell itself.  This is appropriate for
		generating a LEF library from a layout, for which the layout
		itself would be written to a DEF file. <BR>
		Options <B>-hide</B>, <B>-tech</B>, and <B>-toplayer</B> are
		the same as for the <B>lef write</B> command.
	   <DT> <B>nocheck</B> [<I>netname</I> ...]|[<B>none</B>]|[<B>*</B>]
	   <DD> Do not check for antenna diffusion and gate area on the nets with
		the names given as option <I>netname</I>.
		Any number of net names may be given as arguments.  Typically,
		power and ground nets should not need these checks.  If the nets
		are attached to port labels that have been flagged with the use
		"<B>power</B>" or "<B>ground</B>", then these nets will be
		skipped automatically.  If not, then this command option provides
		an alternative way to avoid running the checks, which can cause
		a huge performance hit when generating a LEF view of a large
		layout.  The single argument "<B>*</B>" will cause all net checks
		to be skipped, and no antenna information will appear in the
		LEF file output.  The single argument "<B>none</B>" removes the
		list of net names for which antenna checks should be skipped.
	   <DT> <B>datestamp</B> [<I>value</I>|<B>default</B>]
	   <DD> Force all cell definitions generated from LEF macros to have
		the datestamp (timestamp) of <I>value</I>.  This can be used to
		ensure that the timestamps of abstract views match the timestamps
		of the equivalent full views, so that switching between abstract
		and full views does not cause timestamp mismatch handling.  The
		string <B>default</B> cancels any fixed timestamps.
	   <DT> <B>help</B>
	   <DD> Print help information
	 </DL>
      </BLOCKQUOTE>
   </BLOCKQUOTE>

<H3>Summary:</H3>
   <BLOCKQUOTE>
      The <B>lef</B> command writes LEF-format files, which are files
      containing technology information and information about the content
      of standard cells.  It is used in conjunction with the <B>def</B>
      command to read databases of routed digital standard-cell layouts.
      The <TT>.lef</TT> file shares some information with the technology
      file in <B>magic</B>.  At a minimum, to read <TT>.lef</TT> files
      from third-party sources, the technology file should have a
      <B>lef</B> section that maps magic layers to layer names that are
      found in the <TT>.lef</TT> and <TT>.def</TT> files.  Without
      this information, <B>magic</B> will attempt to make an educated
      guess about the routing layers, which normally will be named
      in an obvious manner such as "metal1", "metal2", etc.  The
      technology file section may be necessary to handle more complicated
      input such as obstruction layers.  Most other aspects of a
      technology will be contained within the <TT>.lef</TT> file.
      When writing <TT>.lef</TT> files, <B>magic</B> will use internal
      layer names for the routing layers if no other information is
      present in the <B>lef</B> section of the technology file. <P>

      Because the <B>lef</B> format allows standard cells to be minimally
      defined (for purposes of protecting intellectual property), often
      the <TT>.lef</TT> file contains no actual layout information for
      the standard cells.  <B>magic</B> provides a command option
      "<B>-import</B>".  When specified, for each macro cell in the
      input <TT>.lef</TT> file, <B>magic</B> will look for a <TT>.mag</TT>
      file of the same name.  If found, it will be loaded and used in
      preference to the definition in the <TT>lef</TT> file. <P>

      Magic uses the <B>port</B> mechanism for labels to determine
      what are the standard cells in a design.  All cells containing
      <B>port</B> labels will be considered standard cells when writing
      a <TT>.lef</TT> file.   Ports retain various bits of information
      used by the LEF/DEF definition, including the port use and
      direction.  See the <B>port</B> documentation for more information.<P>

      Macro cell properties common to the LEF/DEF definition but that
      have no corresponding database interpretation in <B>magic</B>
      are retained using the cell <B>property</B> method in <B>magic</B>.
      There are specific property names associated with the LEF format.
      These are as follows:
      <DL>
	<DT> <B>LEFclass</B>
	<DD> Corresponds to the value of <B>CLASS</B> for a macro
	     cell in the LEF format.
	<DT> <B>LEFsymmetry</B>
	<DD> Corresponds to the value of <B>SYMMETRY</B> for a macro
	     cell in the LEF format.
	<DT> <B>LEFsite</B>
	<DD> Corresponds to the value of <B>SITE</B> for a macro
	     cell in the LEF format.
	<DT> <B>LEFproperties</B>
	<DD> Corresponds to the value of <B>PROPERTY</B> for a macro
	     cell in the LEF format.  LEF properties should be specified
	     in a single cell property, in key:value pairs and space-separated.
	     Like all properties containing spaces, the entire property string
	     should be enclosed in quotes.  When writing output, each of the
	     space-separated entries will be output on its own PROPERTY line
	     in the LEF file.
      </DL>

      Normally, when importing a LEF/DEF layout into <B>magic</B>, one
      will first execute a <B>lef read</B> command followed by a
      <B>def read</B> command.  Likewise, when writing a layout, one
      will first execute a <B>lef writeall -notop</B> command followed
      by a <B>def write</B> command. <P>

      If a LEF file of macro definitions is read when the same cells
      as named in the macros already exist in the magic database, then
      the LEF file macros will be used to annotate the existing layout.
      This includes setting pin properties (see above), extending the
      area of labels to cover an entire port, and setting a bounding
      box on the cell corresponding to the LEF origin and size. <P>

      Note that <B>lef write -hide</B> will generate only the minimum
      amount of obstruction bounding any non-pin geometry inside a
      layout.  To enforce a larger obstruction area, the property
      "<B>OBS_BBOX</B>" can be created in the cell, a string with
      four values for the lower left and upper right corners of the
      bounding box, in magic internal database units.
   </BLOCKQUOTE>

<H3>Implementation Notes:</H3>
   <BLOCKQUOTE>
      <B>lef</B> is implemented as a built-in command in <B>magic</B>.
      Only the critical portion of the LEF syntax has been implemented.
      In particular, simulation-specific properties of the technology
      and of macro cells are not implemented.
   </BLOCKQUOTE>

<H3>See Also:</H3>
   <BLOCKQUOTE>
      <A HREF=def.html><B>def</B></A> <BR>
      <A HREF=port.html><B>port</B></A> <BR>
      <A HREF=property.html><B>property</B></A> <BR>
      <A HREF=snap.html><B>snap</B></A> <BR>
   </BLOCKQUOTE>

<P><IMG SRC=graphics/line1.gif><P>
<TABLE BORDER=0>
  <TR>
    <TD> <A HREF=commands.html>Return to command index</A>
  </TR>
</TABLE>
<P><I>Last updated:</I> June 28, 2021 at 12:28pm <P>
</BODY>
</HTML>
